IBIS Macromodel Task Group Meeting date: 11 October 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: * Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki * Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Bob Ross to send out an updated BIRD 147.2 proposal containing the changes discussed. - Done. - Michael Mirmak to draft a clarification BIRD for AMI Output parameters. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Two sets of minutes needed review, as the September 27th minutes were not prepared and posted in time for the October 4th meeting. - September 27th minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Walter: Second. - Arpad: Anyone opposed? [none] - October 4th minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Radek: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: - Bob R.: [sharing draft 6 of BIRD 147.2] - This is the most recent draft. - The main changes are what we discussed last meeting, plus one change that was from an additional email discussion after the meeting. - In table YY1, required column entries for secondary BCI parameters: "No, Yes if BCI_Protocol is present." - If BCI_Protocol is present, all of the secondary parameters are required. - If BCI_Protocol is absent, all of the secondary parameters must be absent. - BCI_GetWave_Block_UI is now required if BCI_Protocol is present. No default value is provided [this is the change resulting from the email discussion]. - Radek: In the email discussion about removing the default value for BCI_GetWave_Block_UI, one important point was that there was really nothing special about the default value 1000. - Bob R.: So we've gone to an "all or nothing." - If BCI_Protocol is present, all BCI parameters are required. - If BCI_Protocol is absent, all BCI parameters must be absent. - I've moved all of these statements to the Usage Rules: sections, so the locations are now consistent. - Ambrish: What's the default for BCI_Protocol? - Bob R.: There is none. - Radek: We've never had a default for BCI_Protocol in these discussions. - Bob: All we are stating [from BCI_Protocol Usage Notes:] is: - BCI_Protocol names beginning with IBIS are reserved for future protocols adopted and published in this specification. Names for private and independently-specified published protocols should contain character strings sufficiently unique to avoid conflicts with other independently-named protocols. - Arpad: If the BCI_Protocol name does not start with "IBIS" is it automatically considered private? - Ambrish: Yes. - Arpad: If two model makers independently choose the same private protocol name, is that going to be a problem? - Ambrish: We have the same problem with other names, AMI .dlls for example. - There's nothing we can do about it. - Bob R.: We can't really even enforce the rule that a private protocol can't start with "IBIS". - There's no way to check it with the parser, unless we have a table of official "IBIS" protocols. - Ambrish: Wouldn't there be such a list? - Walter: I recall that one of the things you did not want to happen is BCI protocols being tied to IBIS releases. - Ambrish: Yes. - Walter: There may be some sort of process for approving a BCI protocol named IBIS_xyz, but unless it becomes part of the IBIS spec. there's nothing the IBIS parser can check for. - Since we wanted the BCI protocol approvals to be independent of IBIS releases, there's nothing the IBIS parser can check. - I mention this because Bob mentioned the idea of having a table of approved names, and the parser could verify that IBIS_xyz is part of the table. But that would mean it has to be part of the ibischk parser and therefore part of the IBIS release. But we wanted to make protocol approval independent. - I don't think we need to get hung up on this point. - Ambrish: Agreed. - Arpad: In the paragraph where we say private names should be "sufficiently unique to avoid conflicts", should we make a suggestion or even a rule that all private protocol names should start with a vendor or entity name of the model maker's organization? - This would help guarantee uniqueness, and within an organization they could hopefully track their own protocol names. - Ambrish: We didn't try to legislate that with other things like .dll names. - We can, but there's only so far you can go with those recommendations. - Bob R.: We have some general problems. - One is that we are stating that official protocols should begin with "IBIS". - Walter is suggesting that we are not going to officially document these protocols in this specification. That would be contrary to the verbiage "published in this specification". - We may have a separate process for storing approved BCI protocol names, but there would be no enforcement of that. There would also be no way to enforce any restriction on someone having a private unapproved protocol and starting the name with "IBIS". - Arpad: I'm not trying to enforce the "IBIS" rule, I was just suggesting that we could provide a suggestion to help model makers come up with unique names for their private protocols. - Radek: The problem is that "entities" change. - What you're suggesting is doable, but I think what we have is sufficient. - Clearly "my_bci_protocol" would not be sufficiently unique. - What we really want to ensure is that if we have IBIS approved protocols, and a Tx and Rx are using the same approved protocol, that they can talk to each other. - Otherwise, it's really up to the user to make sure the devices are using the same protocol. - Mike L.: I think the current "sufficiently unique" sentence is good enough. - Arpad has proposed some more specific guidance. - Walter: I agree with Mike. - We certainly have the problem with IBIS filenames. - Any naming you rule you come up with is going to fail in some scenario. - I think what we have is sufficient. - We haven't run into trouble with IBIS files. People have dealt with it. - Ambrish: The example could be changed to say "vendor_name_private_1" or something like that to give a hint to the model makers. - Arpad: Okay, we don't have to change it. I just thought we could provide additional suggestions. - Mike L.: I think the example could help. - Also, the first sentence about "IBIS" names being reserved for future protocols is sufficient to implement a parser check that would currently flag an error for any protocol name beginning with "IBIS". - Bob R.: Okay, but we should delete the phrase that they are published "in this specification." - Ambrish: Would they be published in some other specification? - Bob R.: There are two views. Do we want the list of protocols to change with each version of the specification? If so, then we could have something that ibischk can check. Otherwise we'd have no official mechanism to check, so we might just abandon the idea of checking the protocol names. - Mike L.: We may never publish a list of approved protocols, but it doesn't hurt to reserve the names that start with "IBIS" just in case. - Walter: Let's strike the phrase "published in this specification" and replace it with "published by IBIS." - Bob R.: The first sentence [of Other Notes:] already says "by IBIS", so we can just strike "in this specification". - Mike L.: The first sentence should say "by IBIS Open Forum" otherwise there's confusion about IBIS meaning the specification. - Bob R.: Then if it's published by the IBIS Open Forum then we can include it in ibischk. - Walter: We don't want that check tied to IBIS releases, and it will be if it's in the ibischk parser. - Bob R.: BUG reports could allow us to change the parser without changing the IBIS spec. - Radek: I think a list of approved BCI protocols that is independent from the IBIS spec. is in conflict with a stand-alone ibischk parser. - If you want the parser to read the currently approved list, then it would have to go to some location and read the latest file. - For a standalone parser and the IBIS specification, we may not be able to check the most updated list. - I think it's okay to keep it "published by IBIS Open Forum," and we can just leave the parser alone. - Bob R.: A mechanism could be possible to get the parser to link to some prescribed location in ibis.org to get the latest list. - Radek: Yes, if we wanted to. - Ambrish: Exactly, that's something we can resolve later. We could implement something in the future if we want to, but we don't have to worry about it now. - All we have to do now is remove "in this specification." - Bob R.: So the changes are: - Remove "in this specification." - In the first paragraph, approved by "the IBIS Open Forum." - Ambrish: I would also change the example protocol name from "XYZ_Private_1" to use vendor name or protocol name, just to give an idea to the model maker. - Bob M.: I think the word "vendor" would be okay. - Bob R.: Okay, I'll make changes along those lines. - Walter: Motion to submit this BIRD, with the changes discussed, to the Open Forum for approval. - Bob M.: Second. - Arpad: Anyone opposed to submitting this to the Open Forum? [none] Bob Ross and Radek's discussion of Editorial Task Group Issues: - Bob R: [sharing notes from their most recent meeting] - Per Radek's comments, we discussed common reference vs. topologies where there are some elements in the reference path in n-ports. - Example: ---|--R12--|--- ---|--R12--RSS--|--- | | | | R11 R22 = R11 R22 | | | | ---|--RSS--|--- ---|------------|--- (common ref) - The 2-port parameters (e.g., S parameters, Y parameters, Z parameters, etc.) are identical for both topologies. - The difference is that reference path impedance RSS is moved up into the signal path. - If there's physically, say a Z-RSS in the reference path, then one could think that separate reference terminals must be used. This is not necessary, as the 2-port parameters are identical for both cases and both include the impact of Z-RSS. Furthermore, separating the reference terminals leads to incomplete constitutive circuit relationships (equations). - For the above reasons we opt to have n-port topologies with one common reference terminal, the n+1 terminal. - If separating such terminals is needed then for the 4 terminals in the left picture a 3-port, not a 2-port, data needs to be generated. - Radek: We had some discussion related to the IBIS Interconnect draft proposal. - We had a few discussions related to touchstone and unused terminals, and that led to this discussion. - It's relative to what we are doing here in terms of a reference rail. - Bob R.: Yes, what we are calling the [Local Reference] rail. - Bob R.: We also had a discussion that is for the Interconnect Task Group meeting and relates to what the default termination should be for unused ports of an n-port. - Radek: We are both in favor of that being an open circuit. - Bob R.: We've had that discussion in the past, but what we discussed might not be in sync with what's in the current draft interconnect proposal. - Bob: We've decided we want the name [Local Reference] for what we previously called [GND Reference]. - I claim that we can support the concept of [Local Reference], but that we should not change the various voltages in the model as we had previously discussed. That is for discussion. There's no loss in generality because of the other rule we stated that if the [Local Reference] corner values were identical to some other [* Reference] corner values, then their corresponding terminals are considered the same. So if that were [Pullup Reference], as might be done for ECL, then the [Pullup Reference] voltage and its corresponding terminal would be the default reference for C_comp, C_pkg, return currents, etc. We don't need to shift voltages around relative to that reference. - Radek: We haven't arrived at the final common decision on that. - Bob R.: If we declare a [Local Reference] as some other rail, what should the I/O waveform be relative to? Should it be shown relative to the DUT reference or the [Local Reference]. - Radek: How you display the values depends on how you set up the simulation. - We haven't finished that discussion. - Bob R.: Radek had noted an interesting observation. It's possible for a Pin to have the same bus label for the pullup_ref and power_clamp_ref (according to [Pin Mapping]), but for the [Model] associated with that Pin to declare different values for [Pullup Reference] and [POWER Clamp Reference]. This is a possible inconsistency that I think the current parser would not catch. - Radek: We could start checking for that or establishing precedence. - Bob. R.: I think this should simply be an error, as there's no way to know whether the model maker set up the [Pin Mapping] or the [Model] incorrectly. - Bob R.: We also continued our discussion on [Pin Reference] and whether there are any conflicts with [Local Reference]. - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Bob Ross to send out a BIRD 147.2 proposal containing the changes discussed. AR: Mike LaBonte to submit that version of BIRD 147.2 to the Open Forum. ------------- Next meeting: 18 October 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives